The ExtremeXOS implementation of public-key infrastructure (PKI) supports the secure authentication of Syslog server and SSH client to an Extreme Networks XOS device using an X.509 certificate. Below are primary aspects of a PKI configuration (for more information about each command listed in this topic, see ExtremeXOS v33.1.1 Command Reference Guide ):
Note
All the certificates mentioned below should be in PEM format.Note
OCSP processes intermediate CA certificates iteratively, one by one.The OCSP Server‘s address must be configured in the Authority Information Access (AIA) of the peer certificate. Otherwise, the PKI authentication fails. The supported OCSP responder models are: common issuer model, delegated trusted responder model, trusted responder model.
download ssl 10.120.89.79 certificate trusted-ca cacert.pemThe OCSP signature CA is only required for TRM; it is not used for DTM and common issuer. This certificate must contain a trusted use extension that permits OCSP signing. A “trusted use extension” can be appended to a certificate using OpenSSL.
The following example appends a trusted use extension specifying an original file and the trusted file: ocsp-sig-ca.pem is the original certificate file and the output file trusted-ocsp-sig-ca.pem is the trusted file: % openssl x509 -in ocsp-sig-ca.pem -addtrust OCSPSigning -out trusted-ocspsig- ca.pem
-----BEGIN CERTIFICATE----- MIICgTCCAeqgAwIBAgIJAMng4JQ0MOeIMA0GCSqGSIb3DQEBBQUAMGAxCzAJBgNV BAYTAlVTMRIwEAYDVQQKEwlFbnRlcmFzeXMxDDAKBgNVBAsTA0RvRDEMMAoGA1UE CxMDUEtJMSEwHwYDVQQDExhFc3lzIEpJVEMgT0NTUCBSZXNwb25kZXIwHhcNMTIw MjE3MTg0MzEwWhcNMjIwMjE0MTg0MzEwWjBgMQswCQYDVQQGEwJVUzESMBAGA1UE ChMJRW50ZXJhc3lzMQwwCgYDVQQLEwNEb0QxDDAKBgNVBAsTA1BLSTEhMB8GA1UE AxMYRXN5cyBKSVRDIE9DU1AgUmVzcG9uZGVyMIGfMA0GCSqGSIb3DQEBAQUAA4GN ADCBiQKBgQCuyC9QHBpP/n6aOS+Cx0mbgsQTS1LAUUCwxjvJdILGVfdjFB8PKG+o W4jm7FKuRHR7uzBvAFzD9DbVkziHl2yIsy4SeiSBTQpNvHPjvUcec3rTlw7saiTw B+CTqEm1pxcEdRKTvawK2k1ujHML1MABP2CA3SEptO+Ude4UkXMBywIDAQABo0Mw QTAdBgNVHQ4EFgQUYFhsLiklZh0riJ1Hg7d4HPcLlBUwCwYDVR0PBAQDAgGGMBMG A1UdJQQMMAoGCCsGAQUFBwMJMA0GCSqGSIb3DQEBBQUAA4GBADU4aQ6f8pHWLd7z vZ8pJ8e8UCvKok1LmdXbax5TBonyyLmb7AjLrOWjZ7LKSufJL1KOBsetd5Q49LFK h70V2fRWpGNQszpAV60WfidkNvQ0koZczEjYRQOCtMDUqxMHxsMv2MLEVE9QuGLt +NWjeeF03E1DT3C4mnbVsTyWPZij -----END CERTIFICATE----- -----BEGIN TRUSTED CERTIFICATE----- MIICgTCCAeqgAwIBAgIJAMng4JQ0MOeIMA0GCSqGSIb3DQEBBQUAMGAxCzAJBgNV BAYTAlVTMRIwEAYDVQQKEwlFbnRlcmFzeXMxDDAKBgNVBAsTA0RvRDEMMAoGA1UE CxMDUEtJMSEwHwYDVQQDExhFc3lzIEpJVEMgT0NTUCBSZXNwb25kZXIwHhcNMTIw MjE3MTg0MzEwWhcNMjIwMjE0MTg0MzEwWjBgMQswCQYDVQQGEwJVUzESMBAGA1UE ChMJRW50ZXJhc3lzMQwwCgYDVQQLEwNEb0QxDDAKBgNVBAsTA1BLSTEhMB8GA1UE AxMYRXN5cyBKSVRDIE9DU1AgUmVzcG9uZGVyMIGfMA0GCSqGSIb3DQEBAQUAA4GN ADCBiQKBgQCuyC9QHBpP/n6aOS+Cx0mbgsQTS1LAUUCwxjvJdILGVfdjFB8PKG+o W4jm7FKuRHR7uzBvAFzD9DbVkziHl2yIsy4SeiSBTQpNvHPjvUcec3rTlw7saiTw B+CTqEm1pxcEdRKTvawK2k1ujHML1MABP2CA3SEptO+Ude4UkXMBywIDAQABo0Mw QTAdBgNVHQ4EFgQUYFhsLiklZh0riJ1Hg7d4HPcLlBUwCwYDVR0PBAQDAgGGMBMG A1UdJQQMMAoGCCsGAQUFBwMJMA0GCSqGSIb3DQEBBQUAA4GBADU4aQ6f8pHWLd7z vZ8pJ8e8UCvKok1LmdXbax5TBonyyLmb7AjLrOWjZ7LKSufJL1KOBsetd5Q49LFK h70V2fRWpGNQszpAV60WfidkNvQ0koZczEjYRQOCtMDUqxMHxsMv2MLEVE9QuGLt +NWjeeF03E1DT3C4mnbVsTyWPZijMAwwCgYIKwYBBQUHAwk= -----END TRUSTED CERTIFICATE-----
OCSP nonce cryptographically binds an OCSP request and an OCSP response with an id-pkix-ocsp-nonce extension to prevent replay attacks.
OCSP override configures one HTTP Online Certificate Status Protocol (OCSP) override URL for an SSH2 x509v3 server.
When OCSP-nocheck is done for a peer certificate, ExtremeXOS sends the OCSP request to the OCSP server. The OCSP response is signed by the OCSP responder/signer. The response also comes along with the certificate of the OCSP signer. When ExtremeXOS receives the response, it only verifies that the status of the peer certificate is not revoked.